A method for controlling communication between a universal integrated circuit card (UICC) and an external device provides that a handset including the UICC executes some steps to drive the connection between the UICC and the external device. With reference to FIG. 1, a communication environment between a UICC 10 and an external device 14, for example, a PC 14, via Bluetooth is shown. The UICC 10 is plugged into the handset 12. The PC 14 is coupled to a server 16 via the Internet or other types of network connections. An external application resides in the PC 14 or in the server 16 for communicating with the UICC 10. The handset 12 is coupled to PC 14 via Bluetooth 18. The Bluetooth SIM Access Profile (SAP) can be used for communication between the UICC 10 and PC 14.
When the handset 12 is in the range of a device supporting Bluetooth SAP, i.e. PC 14, they may be connected. The connection can be automatic or triggered upon a positive command of the handset 12 user, who is prompted with a notification message on the handset 12 display. When the handset 12 and the PC 14 are coupled, the handset 12 stops sending Application Protocol Data Unit (APDU) generated by itself to the UICC 10. It rather starts sending to the UICC 10 the APDUs received from the external device 14. Any type of APDU is dispatched. For example, if the Bluetooth SAP enabled external device 14 includes telecommunication capabilities, it works as a mobile telephone using the mobile number and network authentication credentials related to the UICC 10, while this is still inserted in the handset 12. This is a common situation, since many current SAP devices are hands-free speaker car-kits. In this case, UICC 10 is not aware of which, the handset 12 or the external device 14, is accessing it in a given moment.
More particularly, the steps described above with reference to FIG. 1 include: switching on the UICC by an handset including the UICC; executing a first initialization procedure by the handset, to establish a first communication session between the handset and the UICC; sending a connection request to the handset by the external device or vice versa, to establish a second communication session between the UICC and the external device; and executing a second initialization procedure between the external device and the UICC.
The second initialization procedure may be needed since the UICC and the external device have to exchange information about their respective characteristics to operate correctly. In particular, external devices could have different characteristics with respect to the handset.
Several problems may occur in the communication between the UICC and the external device described above. A first problem may occur after a successful PIN authentication of the external device, for example, because an application of the external device may access the user's personal data while pretending it is furnishing a certain service or data. Otherwise, the application can modify the personal data stored in the UICC 10 without authority. Another problem may occur because the UICC operability is interrupted, for example, because the external device 14 performs a PIN verification with a wrong PIN: after just few attempts, the UICC 10 is blocked by the incorrect PIN input, and this blocks all other access from other applications until the owner of UICC 10 resets the handset 12 and inputs the correct unblock number (PUK) for the UICC. Nevertheless, the UICC operability may be compromised if the external device 14 performs a small series of PIN unblocks with a wrong PUK number. In all these cases, the UICC 10 cannot detect whether it is coupled by the handset 12 or by the third-party's external application, i.e. by the external device, and thus it simply responds to the requests as they arrive from the handset.
In several application environments, including an interaction of UICC with Internet oriented environments, such as the USB protocol, Smart Card Web Server, W-LAN and GBA, would be very useful to use the high confidential credential information on the UICC to authenticate the user. This would allow launching business models with 3rd parties and Web merchants providing authentication services based on UICC, with the network operator able to identify and provide/guarantee the user identity, for example, for purchasing over the Internet with the user credential authenticated by the UICC.
However, while the direct communication between an external device, such as a PC, and the UICC gives a convenience to the user, it can threaten the security and privacy of the handset owner, since the UICC 10 cannot detect whether it is logically connected to the handset or to the third-party's external application running on the external device, and it simply responds to the requests as they arrive from the handset. Thus, unauthorized software can access some of the private information contained in UICC without granted permission from the owner of UICC, and dangerous software can act as a virus to the whole system.
It's worth noting that an external device, such as a PC, enabled to communicate with an UICC using a wireless protocol is more critical than a personal handset from the security point of view. In fact, the external device could not be either maintained or owned by the UICC owner, since it could be a service offered in a public environment (bar, cinema, museum, transportation station). Therefore, the UICC owner cannot safeguard its security; moreover, a PC is more vulnerable to viruses and malicious software than typical handsets, because of the higher grade of programmability. Nevertheless, the same issues could also affect a personal handset.